home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Aug-Sep 88 / re Jump Table entries ⁄ < prev    next >
Encoding:
Text File  |  1991-03-06  |  5.7 KB  |  115 lines  |  [TEXT/GEOL]
  1. Item    5618045                         22-Aug-88        22:07
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     D0416                           Futuresoft System Design, Dev
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re Jump Table entries
  10.  
  11. Your suggestions are in the right direction.  Here are some of my comments.
  12.  
  13. Reallocating the global space between jump table entries and global data would
  14. work technically, but wouldn't be a long-term fix.  The most you could have
  15. would be 8,000 jump table entries, at the expense of all your global data.
  16.  
  17. Your second suggestion is on the right track, although I don't think it is not
  18. technically feasible as written.  The linker cannot change a 4-byte method call
  19. into a 6-byte call.  (It can only edit instructions in ways that don't change
  20. their size.)
  21.  
  22. Your third suggestion is better (since it doesn't require patches to the
  23. Segment Loader), but you still need to have the offset into the segment
  24. somewhere.  You could make a call be jsr xxxx(a5) to the segment-specific
  25. dispatcher, followed by the 2-byte offset.  You would still have to make all
  26. calls be 6-bytes because the compiler (which determines the number of bytes in
  27. the call) cannot know which kind of linkage conventions to use.
  28.  
  29. Your suggestions, however, only address the use of jump tables to cause
  30. segments to be loaded, and don't address the special circumstances of Object
  31. Pascal.
  32.  
  33. Object Pascal method calls are different than normal subroutine calls because
  34. they go through a method dispatcher.  Therefore, one could enhance the method
  35. dispatcher to also load the required code segment.  Right now the method
  36. dispatcher uses the standard Segment Loader for this purpose.  Essentialy this
  37. means moving the jump table entries into the method tables, and changing the
  38. method dispatcher to deal with loading segments.  The entries in the method
  39. table are not accessed via indexing, so there is no limit on their number.
  40.  
  41. The minimum stuff you need in a jump table entry is the code segment id and the
  42. offset within the segment, which amounts to 4 bytes.  Normal jump table entries
  43. are twice that; the extra space is used to cache the absolute address of the
  44. code so that when the segment is already loaded the call is very fast.  (The
  45. extra space also makes cross-segment calls much simpler.)
  46.  
  47. Right now method table entries are 2 bytes, so you would double the size of the
  48. method tables.  But you would also eliminate all the normal jump table entries
  49. and get a net space savings.  (Note that methods cannot be called except
  50. through the method dispatcher, so you don't need the standard jump table
  51. entries.)  I think you would see a performance decrease, however, because of
  52. the less efficient handling of the already-loaded-segment case.
  53.  
  54. If method table entries were 8 bytes you could cache the abolute addresses and
  55. still not have a net space increase over the current implementation.  You
  56. couldn't use the jump table format used by the Segment Loader, however.  The
  57. Segment Loader depends on being able to quickly locate all the jump table
  58. entries referring to a particular segment.  Without some additional storage, it
  59. would be fairly slow to locate all the method table entries that refer to a
  60. particular segment.
  61.  
  62. Object Pascal also uses the jump table for 2 other purposes.  (This is why
  63. Object Pascal programs use a lot of jump table entries.)  When you make a
  64. method call, you need to tell the method dispatcher the method ID you are
  65. calling.  The dispatcher gets the class ID of the object on the stack and uses
  66. these 2 IDs to look up the address of the method.
  67.  
  68. Since the method id is 2 bytes, you would think that a method call would
  69. require 4 bytes for the jsr and 2 bytes for the ID.  We were able to make
  70. method calls only 4 bytes by making the method ID be the jump table offset.
  71. (This also had the advantage that the linker uniquely assigns jump table
  72. offsets, so it would automagically assign unique method ids.)
  73.  
  74. In the same way, we make the class ID be the jump table offset to the class'
  75. method table, so that it is easy to locate the method table.
  76.  
  77. If one is willing to increase all method calls from 4 bytes to 6, then we don't
  78. need a jump table entry to represent the method ID.  A method call would be a
  79. 4-byte jsr to the method dispatcher followed by a 2-byte method id.  The linker
  80. would have to be modified to uniquely assign these ids.
  81.  
  82. Alternatively, if there was a fast way to make a 2-byte subroutine call, we
  83. could still keep method calls at 4-bytes.  An A-Trap is a 2-byte subroutine
  84. call, but it is not fast.  (This would double the time needed to call a
  85. method.)  The jsr(a5) instruction is fast and only 2 bytes, but the location
  86. pointed to by a5 is used by Quickdraw.  (On the Lisa, this location was free,
  87. and we did use this implementation.)
  88.  
  89. To summarize:
  90.  
  91. If method calls were increased from 4 to 6 bytes, you could eliminate one use
  92. of jump table entries in Object Pascal.  This saves one jump table entry per
  93. defined method.
  94.  
  95. If the linker generates unique class IDs, then you could eliminate one jump
  96. table entry per class.
  97.  
  98. If the method dispatcher handled segment loading, then you could eliminate one
  99. jump table entry per implemented method.
  100.  
  101. In all cases the linker would have to be changed to generate new IDs or tables.
  102.  The first of these changes would increase the size of programs somewhat; the
  103. other 2 changes would not increase the size much (if any).
  104.  
  105. The compiler would also have to be changed, which impacts not only MPW Pascal,
  106. but also MPW C++ and TML Pascal.  Also, if you change the optimized runtime
  107. implementation, then you can't use the ROM method dispatcher.  This would slow
  108. down programs that execute on the Mac Plus and Mac SE.
  109.  
  110.  
  111. Larry Rosenstein
  112.  
  113.  
  114.  
  115.